Generic Bootstrapping Architecture (GBA) is a technology, standardized at the 3rd Generation Partnership Project (3GPP), that provides authentication and application security based on 3GPP subscription credentials. Instead of having separate authentication credentials for each service a user intends to use, the user can authenticate himself using the 3GPP subscription credentials to all services. This authentication is possible if the user has a valid identity on a Home Location Register (HLR) or on a Home Subscriber Server (HSS), i.e. if the user has 3GPP subscription credentials with an operator of a wireless network.
The GBA thus makes it possible for users to authenticate themselves to services using the 3GPP subscription credentials. In GBA, a service is denoted Network Application Function (NAF). Details of the GBA authentication can be found in the GBA specification 3GPP TS 330.220, and the authentication function provided by GBA is briefly described with reference to FIG. 1.
In FIG. 1, a user having some kind of device 1 wants to access a service, for instance social network services such as Facebook, LinkedIn, Twitter, Myspace etc. A Bootstrapping Server Function (BSF) 2 of the operator network (denoted 3GPP network in the FIG. 1) provides a user identity that the user has within the service, e.g. user@socialnetwork.com, to the NAF 4, whereby the user can be authenticated in the service. The BSF 2 gets User Security Settings (USS) from a Home Location Register (HLR) or from a Home Subscriber Server (HSS) 3 as part of GBA User Security Settings (GUSS). This mechanism assumes that the service user identity, e.g. user@ socialnetwork.com or more generally user ID@NAF, has been mapped to the 3GPP subscription in the USS beforehand, i.e. that the service user identity is preconfigured in the USS, as indicated at reference numeral 5.
In FIG. 2 the above is next described a bit more in detail. The device 1 with 3GPP credentials (the device being denoted user equipment, UE, in FIG. 2) tries to access a GBA enabled service, i.e. NAF 4, using a user name userID@NAF and with an application protocol such as for instance Hypertext Transfer Protocol (HTTP), arrow 100. The NAF 4 will reply with a HTTP 401 message, arrow 101, requesting the device 1 to authenticate itself. The device 1 will next run the bootstrapping towards the BSF 2. By means of the bootstrapping, indicated at reference numeral 102, the device 1 and the BSF 2 mutually authenticate each other. In addition, both parties generate master key Ks, and the BSF 2 provides the device 1 with an identifier denoted Bootstrapping Transaction Identifier, B-TID, for the authentication run towards the NAF. Next, indicated at box 103, the device 1 generates a NAF specific key, denoted KsNAF, based on the master key Ks. The device 1 calculates a response using the KsNAF, indicated at box 104, and replies (arrow 105) to the 401 message received from the NAF 4, using the NAF specific key KsNAF as the password and the bootstrapping identifier B-TID as the username.
It is noted that there are several types of NAF specific keys, depending on what variant of GBA that is used. So called GBA_ME, which is a Mobile Equipment based GBA, produces a key denoted Ks_NAF, while so called GBA_U, which is GBA with Universal Integrated Circuit Card (UICC)-based enhancements, produces keys denoted Ks_int_NAF and Ks_ext_NAF. For the sake of simplicity the term KsNAF is used throughout the description, and intended to encompass any of the mentioned NAF specific keys.
The NAF 4, which has a trust relationship with the BSF 2, queries (arrow 106) the BSF 2 for the NAF specific key KsNAF by using the B-TID. The BSF 2 generates the (box 107) NAF specific key KsNAF and provides it to the NAF 4 (arrow 108). The NAF 4 can now authenticate the device 1 using the NAF specific key KsNAF. In particular, at box 109, the NAF 4 verifies the response from the device 1 using the KsNAF and the user is authenticated as userID@NAF (box 110). The NAF 4 may also send an HTTP 200 message to the device 1 (arrow in).
The reply (arrow 108) from the BSF 2 to the NAF 4 also comprises the user identity, e.g. International mobile Subscriber Identity (IMSI), IMPI, Mobile Subscriber Integrated Services for Digital Network Number (MSISDN) or some other information stored in the HSS/HLR 3, in particular the GUSS thereof, for the subscription/service/NAF. This user identity is to be used for the user in the service, i.e. the user identity provides a mapping to the account at the service requiring authentication.
However, it has not been defined how to map the 3GPP subscription to a valid user account in the service, instead is has been left as a configuration matter. Continuing the above example, the user has an account in a social network providing access through a web-site, socialnetwork.com, with the username user@socialnetwork.com. If the user utilizes GBA to authenticate himself to the service, he would still, for simplicity, like to be using that same account and username. If the user would be allowed to simply configure the username into the HSS/HLR 3, he could easily add an account of some other user, e.g. victimuser@ socialnetwork.com, to the HSS/HLR 3. This would allow him, as an attacker, to log into the other user's (the victim's) account in the service, i.e. to victimuser@ socialnetwork.com in this example.
Further, if the user wants to access an account with multiple 3GPP subscriptions using GBA, each of the subscriptions would need to be securely mapped to the same account in the NAF.
The above described lack of secure mapping of subscriptions to service account information is relevant also in other authentication situations, besides the described GBA case.
From the above it is clear that a secure way of adding service account information, such as for instance service user identity or username in a service of a service provider, to an operator network is needed. For instance, the adding of service account information to a HSS/HLR 3 of an operator network would be desirable.